Global Illumination - Discarded Solutions

Voxel Cone Tracing GI (VCT) / Voxel GI / Sparse Voxel Octree GI (SVOGI) / Voxel Traced Global Illumination (VTGI)

• Interactive Indirect Illumination Using Voxel Cone Tracing - 2011 .

• Dynamic Voxel Based Global Illumination .

• Instead of using rays, we use voxel cones.

•   .

  • This is a high resolution of voxelization.

• Just like mipmaps, we generate lower and lower resolutions of this.

• And cones are used, where each cone accounts for a range of directions, instead of a single direction.

• .

• The cone tracing technique works best with a regular voxel grid because we perform ray-marching against the data like with screen space reflections for example.

• A regular voxel grid consumes more memory, but it is faster to create (voxelize), and more cache efficient to traverse (ray-march).

• The nice thing about this technique is that we can retrieve all sorts of effects. We have “free” ambient occlusion by default when doing this cone tracing, light bouncing, but we can retrieve reflections, refractions and shadows as well from this voxel structure with additional ray march steps. We can have a configurable amount of light bounces. Cone tracing code can be shared between the bouncing and querying shader and different types of rays as well. The entire thing remains fully on the GPU, the CPU is only responsible for command buffer generation.

• Limitations / Drawbacks :

  • The main drawback being the limited resolution.

  • Voxel GI gives plausible multi-bounce GI but costs in memory, bandwidth and costly voxelization/update;

  • The UE5 presentation does make a good argument against cone tracing for generic use (which unreal engine targets), there will always be some artifacts and those will be super bad in specific scenes.

  • Comparing to RTGI, voxel based is faster but less accurate and less dynamic.

  • Voxel-based lighting is only faster than ray traced global illumination solutions that favor quality over performance. RTGI solutions that prioritize performance are faster than Voxel cone tracing.

  • Indiana Jones runs at 1080 60FPS on Series S with RTGI and KCD2 runs at 1080P 30 FPS on Series S.

  • Voxel cone tracing is an obsolete technological dead end - too heavy to run on last-gen consoles and mobile, inferior to RT on modern desktop and console hardware.

  • KCD2 (Kingdom Come: Deliverance II) only uses it because CryEngine supports it but doesn’t support ray tracing. And CryEngine is still stuck using voxel lighting because the Star Citizen devs poached CryTek’s best graphics engineers, and those engineers then proceeded to add ray tracing to Star Citizen’s fork of CryEngine.

  • SVOGI is inaccurate as balls.

  • You must love light leaking through every room corner. It's cheap crappy raytracing and it looks like cheap crappy raytracing.

• Implementation :

  • Wicked Engine Implementation .

  • First, we have our scene model with polygonal meshes. We need to convert it to a voxel representation. The voxel structure is a 3D texture which holds the direct illumination of the voxelized geometries in each pixel. There is an optional step here which I describe later. Once we have this, we can pre-integrate it by creating a mipmap chain for the resource. This is essential for cone tracing because we want to ray-march the texture with quadrilinear interpolation (sampling a 3D texture with min-mag-mip-linear filtering). We can then retrieve the bounced direct illumination in a final screen space cone tracing pass. The additional step in the middle is relevant if we want more bounces, because we can dispatch additional cone tracing compute shader passes for the whole structure (not in screen space).

  • 1.) Voxelization :

    • The most involving part is definitely the first one, the voxelization step. It involves making use of advanced graphics API features like geometry shaders, abandoning the output merger and writing into resources “by hand”. We can also make use of new hardware features like conservative rasterization and rasterizer ordered views, but we will implement them in the shaders as well.

    • The main trick to be able to run this in real time is that we need to parallelize the process well. For that, we will exploit the fixed function rasterization hardware, and we will get a pixel shader invocation for each voxel which will be rendered. We also do only a single render pass for every object.

    • We need to integrate the following pipeline to our scene rendering algorithm:

    • 1.) Vertex shader

    • The voxelizing vertex shader needs to transform vertices into world space and pass through the attributes to the geometry shader stage. Or just do a pass through and transform to world space in the GS, doesn’t matter.

    • 2.) Geometry shader

    • This will be responsible to select the best facing axis of each triangle received from the vertex shader. This is important because we want to voxelize each triangle once, on the axis it is best visible, otherwise we would get seams and bad looking results.

    // select the greatest component of the face normal input[3] is the input array of three vertices
    float3 facenormal = abs(input[0].nor + input[1].nor + input[2].nor);
    uint maxi = facenormal[1] > facenormal[0] ? 1 : 0;
    maxi = facenormal[2] > facenormal[maxi] ? 2 : maxi;
    

    • After we determined the dominant axis, we need to project to it orthogonally by swizzling the position’s xyz components, then setting the z component to 1 and scaling it to clip space.

    for (uint i = 0; i < 3; ++i)
    {
    // voxel space pos:
        output[i].pos = float4((input[i].pos.xyz - g_xWorld_VoxelRadianceDataCenter) / g_xWorld_VoxelRadianceDataSize, 1);
        // Project onto dominant axis:
        if (maxi == 0)
        {
            output[i].pos.xyz = output[i].pos.zyx;
        }
        else if (maxi == 1)
        {
            output[i].pos.xyz = output[i].pos.xzy;
        }
        // projected pos:
        output[i].pos.xy /= g_xWorld_VoxelRadianceDataRes;
        output[i].pos.z = 1;
        output[i].N = input[i].nor;
        output[i].tex = input[i].tex;
        output[i].P = input[i].pos.xyz;
        output[i].instanceColor = input[i].instanceColor;
    }
    

    • At the end, we could also expand our triangle a bit to be more conservative to avoid gaps. We could also just be setting a conservative rasterizer state if we have hardware support for it and avoid the expansion here.

    
    // Conservative Rasterization setup:
    float2 side0N = normalize(output[1].pos.xy - output[0].pos.xy);
    float2 side1N = normalize(output[2].pos.xy - output[1].pos.xy);
    float2 side2N = normalize(output[0].pos.xy - output[2].pos.xy);
    const float texelSize = 1.0f / g_xWorld_VoxelRadianceDataRes;
    output[0].pos.xy += normalize(-side0N + side2N)*texelSize;
    output[1].pos.xy += normalize(side0N - side1N)*texelSize;
    output[2].pos.xy += normalize(side1N - side2N)*texelSize;
    

    • It is important to pass the vertices’ world position to the pixel shader, because we will use that directly to index into our voxel grid data structure and write into it. We will also need texture coords and normals for correct diffuse color and lighting.

    • 3.) Pixel shader

    • After the geometry shader, the rasterizer unit schedules some pixel shader invocations for our voxels, so in the pixel shader we determine the color of the voxel and write it into our data structure. We probably need to sample our base texture of the surface and evaluate direct lighting which affects the fragment (the voxel). While evaluating the lighting, use a forward rendering approach, so iterate through the nearby lights for the fragment and do the light calculations for the diffuse part of the light. Leave the specular out of it, because we don’t care about the view dependent part now, we want to be able to query lighting from any direction anyway later. I recommend using a simplified lighting model, but try to keep it somewhat consistent with your main lighting model which is probably a physically based model (at least it is for me and you should also have one) and account for the energy loss caused by leaving out the specularity.

    • When you calculated the color of the voxel, write it out by using the following trick: I didn’t bind a render target for the render pass, but I have set an Unordered Access View by calling OMSetRenderTargetsAndUnorderedAccessViews(). So the shader returns nothing, but we write into our voxel grid in the shader code. My voxel grid is a RWStructuredBuffer here to be able to support atomic operations easily, but later it will be converted to a 3D texture for easier filtering and better cache utilization. The Structured buffer is a linear array of VoxelType of size gridDimensions X Y Z. VoxelType is a structure holding a 32 bit uint for the voxel color (packed HDR color with 0-255 RGB, an emissive multiplier in 7 bits and the last bit indicates if the voxel is empty or not). The structure also contains a normal vector packed into a uint. Our interpolated 3D world position comes in handy when determining the write position into the buffer, just truncate and flatten the interpolated world position which you received from the geometry shader. For writing the results, you must use atomic max operations on the voxel uints. You could be writing to a texture here without atomic operations, but using rasterizer ordered views, but they don’t support volume resources, so a multi pass approach would be necessary for the individual slices of the texture.

    • An additional note: If you have generated shadow maps, you can use them in your lighting calculations here to get more proper illumination when cone tracing. If you don’t have shadow maps, you can even use the voxel grid to retrieve (soft) shadow information for the scene later.

  • 2.) Filtering the data :

  • 3.) Cone Tracing :

    • We have the voxel scene ready for our needs, so let’s query it for information. To gather the global illumination for the scene, we have to run the cone tracing in screen space for every pixel on the screen once. This can happen in the forward rendering object shaders or against the gbuffer in a deferred renderer, when rendering a full screen quad, or in a compute shader. In forward rendering, we may lose some performance because of the worse thread utilization if we have many small triangles. A Z-prepass is an absolute must have if we are doing this in forward rendering. We don’t want to shade a pixel multiple times because this is a heavy computation.

    • For diffuse light bounces, we need the pixel’s surface normal and world position at minimum. From the world position, calculate the voxel grid coordinate, then shoot rays in the direction of the normal and around the normal in a hemisphere. But the ray should not start at the surface voxel, but the next voxel along the ray, so we don’t accumulate the current surface’s lighting. Begin ray marching, and each step sample your voxel from increasing mip levels, accumulate color and alpha and when alpha reaches 1, exit and divide the distance travelled. Do this for each ray, and in the end divide the accumulated result with the number of rays as well. Now you have light bounce information and ambient occlusion information as well, just add it to your diffuse light buffer.

    • Assembling the hemisphere: You can create a hemisphere on a surface by using a static array of precomputed randomized positions on a sphere and the surface normal. First, if you do a reflect(surfaceNormal, randomPointOnSphere),  you get a random point on a sphere with variance added by the normal vector. This helps with banding as discrete precomputed points get modulated by surface normal. We still have a sphere, but we want the upper half of it, so check if a point goes below the “horizon” and force it to go to the other direction if it does:

• VoxelGI - Godot .

  • Good reflections and indirect lighting, but beware of leaks.

  • Due to its voxel-based nature, VoxelGI will exhibit light leaks if walls and floors are too thin. It's recommended to make sure all solid surfaces are at least as thick as one voxel.

  • Streaking artifacts may also be visible on sloped surfaces. In this case, tweaking the bias properties or rotating the VoxelGI node can help combat this.

  • Performance :

    • The bake's number of subdivisions can be adjusted to balance between performance and quality. The VoxelGI rendering quality can be adjusted in the Project Settings. The rendering can optionally be performed at half resolution (and then linearly scaled) to improve performance significantly.

• SVOGI - CryEngine .

• SVOGI - Demo in Kingdom Come: Deliverance .

  • The voxel based approach from the "old" CryEngine 3 was fascinating and it's a real shame very few games effectively supported it.

• Voxel Cone Tracing GI - Demo 2011 .

  • I think it's actually viable for a commercial project. At very least as a fallback for RTX (where it's unsupported or inefficient). I also working on porting it to Unity HDRP.

  • Shame Voxel Cone Tracing/VXGI is not even used as a fallback whenever DXR (DirectX Raytracing) is not supported.

Voxel Cone Traced Reflections

• Sometimes used for specular approximation.

• Voxel Traced GI/Reflections - Demo 2019 .

Global Illumination Based on Surfels (GIBS) (Surfel GI)

• Global Illumination Based on Surfels - EA 2021 .

• Surfel Maintenance for Global Illumination - January 2025 .

• Impressions :

  • It is a technique different from the classic ones currently used. It does not use probes or voxels.

  • It is a somewhat elegant technique.

  • The presentation covers many of the points I had doubts about, it seems well developed.

  • I believe that if the camera moves very quickly, or a new scene appears in front of the player quickly, the technique suffers because it has to update all the surfels.

• Surfel-based GI is not inherently ray-traced, however, EA GIBS implementation (and several production uses) do use ray queries/ray tracing as the primary means to place surfels and to evaluate visibility/irradiance, so practical surfel-GI systems are often implemented with ray tracing.

• It is completely geared toward Raytracing, given its nature.

• Frostbite Engine / EA.

• An image is discretized in pixels, a surface is discretized in surfels.

• It's an interactive screen space gap filling.

• The screen is split into 16x16 tiles and the algorithm finds the tile with the lowest surfel coverage.

• If a tile passes a randomized threshold, spawn a surfel.

• The result is cached for further use.

• Uses Radial Gaussian Depth, inspired by DDGI.

• One surfel shares the irradiance with another surfel.

Screen-Space Indirect Lighting (SSIL)

• “Where should I add  light because nearby surfaces reflect it?”

• SSIL tries to estimate the contribution of nearby surfaces reflecting light into shaded areas, using only the information already available in the screen-space buffers (depth, normals, and sometimes color).

• Can both darken (occlusion) and brighten areas by adding bounced light.

• Think of SSIL as color bleeding + soft bounce lighting in screen space.

• Many SSIL techniques use analytic / horizon-based or hemisphere sampling approaches, and some SSIL variants use screen-space ray-marching (ray-marching against the depth buffer). SSIL only becomes hardware/world-space ray-tracing if you explicitly add a BVH-trace pass (i.e. a hybrid that is no longer “pure” screen-space).

• SSIL - Godot .

  • SSIL provides indirect lighting for small details or dynamic geometry that other global illumination techniques cannot cover. This applies to bounced diffuse lighting, but also emissive materials.

  • SSIL also provides a subtle ambient occlusion effect, similar to SSAO, but with less detail.

  • Good secondary  source of indirect lighting, but no reflections.

  • SSIL works best for small-scale details, as it cannot provide accurate indirect lighting for large structures on its own. SSIL can provide real-time indirect lighting in situations where other GI techniques fail to capture small-scale details or dynamic objects. Its screen-space nature will result in some artifacts, especially when objects enter and leave the screen. SSIL works using the last frame's color (before post-processing) which means that emissive decals and custom shaders are included (as long as they're present on screen).

  • Usage :

    • This feature only provides indirect lighting . It is not  a full global illumination solution.

      • This makes it different from screen-space global illumination (SSGI) offered by other 3D engines.

    • SSIL is meant to be used as a complement to other global illumination techniques such as VoxelGI, SDFGI and LightmapGI.

    • SSIL can be combined with SSR and/or SSAO for greater visual quality (at the cost of performance).

    • When SSIL is enabled on its own, the effect may not be that noticeable, which is intended.

  • Performance :

    • The SSIL quality and number of blur passes can be adjusted in the Project Settings. By default, SSIL rendering is performed at half resolution (and then linearly scaled) to ensure a reasonable performance level.

SSGI (Screen-Space Global Illumination)

• "Standard raytracing in screenspace".

• It is an image-space approximation that often uses screen-space ray-marching or hemisphere sampling (i.e. “rays” marched through the depth buffer), which is different from hardware/true world-space ray tracing.

• Computes GI from information available in the screen buffer (depth, normals). Fast but limited to visible surfaces and can produce artifacts.

• Screen-space sampling / ray marching in screen-space. Not a full ray tracer.

• Most real-time SSGI implementations use temporal and/or spatial denoising (or temporal accumulation) because the raw results are noisy or contain high-frequency sampling error unless you pay a high sampling cost.

• Implementing SSGI with Joint Bileteral Filtering as a Denoiser .

  • It also discusses techniques for reducing GI resolution and using image upscaling; this improves performance with practically no visual difference.

  • Etc; several other small techniques are discussed.

  • All of this in the video was made to apply a ReShade  to Skyrim; in the final seconds of the video the before-and-after difference with the new GI technique is shown.

• SSGI in Unreal Engine 5 .

  • Is a feature that aims to create natural-looking lighting by adding dynamic indirect lighting to objects within the screen view. SSGI also makes it possible to have dynamic lighting from emissive surfaces, such as neon lights or other bright surfaces.

  • Screen Space Global Illumination works best as a supplimental indirect lighting illumination method to precomputed lighting from Lightmass .

  • SSGI, like other screen space effects, is best used in conjunction with other indirect lighting techniques, such as precomputed lighting from lightmass . When you have large objects that block portions of the screen, SSGI becomes apparent when it's being used as the sole indirect lighting illumination for the scene. For example, using baked lighting reduces screen space artifacts when transitioning behind a large occluder where a bright object may be located. SSGI is recommended as a means to improve indirect lighting illumination in your scene but not as a sole indirect lighting method.

• SSGI in Unity .

• Wicked Engine 2024 .

  • I also experimented with a screen space global illumination (SSGI) that I wanted to base on the “multi scale screen space ambient occlusion” (MSAO) that I got from the DirectX Miniengine .

  • Just like MSAO, I wanted SSGI to not have to use any temporal accumulation.

  • This technique currently can only add lighting, not remove it, but it’s meant to be used together with MSAO which handles only ambient occlusion. However, I might revisit and improve this because in real scenes I didn’t find its quality good enough, especially on small scale as I had to use a lot of blur to hide the sub-sampling.

• SSGI only provides bounce lighting for objects that are on the screen, meaning if you have a large red object that is bouncing red light into the scene, and you turn away, all the red light disappears.

• That’s a pretty big limitation but it can work in some cases, such as top-down camera views. Those usually don’t have significant overlapping elements and objects take up less of the screen space so lighting changes usually aren’t as jarring.

• I wouldn’t use it as the sole source of GI for a first/third person project, but it can be used to augment baked lighting, as it will provide bounce light and occlusion for movable objects/lights that otherwise wouldn’t.

• Think of SSGI as a subset/approximation of what path tracing  would compute, but with significant limitations:

  • Path tracing can see the entire scene, SSGI only sees what’s on screen.

  • Path tracing accounts for multiple bounces, SSGI usually only approximates one diffuse bounce.

  • Path tracing is unbiased (given enough samples), SSGI is inherently biased.

• Bad implementations of SSGI can run worse than some Path Tracing implementations.

SSRTGI (Screen-Space Ray-Traced Global Illumination)

• SSGI vs SRTGI :

  • All SSRTGI implementations are SSGI (because they use screen buffers), but not all SSGI implementations are SSRTGI (because some use hemisphere sampling, cone approximations, analytic occlusion, or other non-ray-march methods).

  • Instead of sampling nearby pixels like SSGI does, SSRTGI performs actual ray marching or ray queries in screen space to simulate diffuse rays bouncing off surfaces.

  • Honestly... it seems the same thing, the term sounds interchangeable.

• Still limited to screen-space data (can’t see off-screen geometry), but captures more accurate light transport within the visible region.

• Usually produces better spatial coherence and more accurate occlusion than SSGI. Can also support multiple samples per pixel for more realistic diffuse scattering.

• Heavier than SSGI because of ray marching and denoising. However, still cheaper than full path tracing since it avoids tracing into the full scene BVH.

Ray-Traced Ambient Occlusion (RTAO)

• RTAO Implementation .

  • Ray Traced Ambient Occlusion (RTAO) implemented using DirectX Raytracing (DXR)

Ray-Traced Global Illumination (RTXGI)

• NVIDIA’s RTXGI is implemented as volumes of probes (probe grids/DDGI-style) where probes are updated (ray-traced) and store irradiance/distance-to-geometry for shading.

• RTXGI fits into the modern game engine by directly replacing existing indirect lighting approaches such as screen-space ray casting, precomputed lightmaps, and baked irradiance probes. We combine ray tracing, fast irradiance updates, and a moment-based depth scheme for occlusion calculations to create a scalable system without bake times or light leaks. RTXGI is supported on any DXR-enabled GPU and provides developers with an ideal starting point to bring the benefits of real-time ray tracing to their existing tools, knowledge, and capabilities.

• RTXGI .

• RTXGI .

  • RTXGI v2.0 Update including Neural Radiance Cache and Spatial Hash Radiance Cache

• RTXGI .

• Usage :

  • RTXGI is less prominent as a mainstream, engine-integrated solution today.

  • Industry momentum has shifted toward hybrid ray-tracing + sampling/resampling approaches (Lumen, ReSTIR/RTXDI, hardware path tracing) and improved probe/volume variants (DDGI/modern probe grids).

• Unreal Engine :

  • Available on UE4 with the RTXGI Plugin and NVIDIA maintained an RTX-focused UE branch, and some community forks claim UE5 support, but RTXGI is not the default/integrated GI in mainline Unreal Engine 5  and NVIDIA’s official plugin work was effectively put on hold/limited after early UE5 versions.

  • Unreal Engine 5 uses Lumen.

Ground Truth Ambient Occlusion (GTAO)

• “Practical Realtime Strategies for Accurate Indirect Occlusion" - 2016 .

• Works almost identically to HBAO, but with a few key differences:

  • The heavy math is moved outside of the loop, needed to be calculated once per slice, so the performance is comparable with HBAO+.

  • Consider the cosine of the angle, just like HBAO+ does.

Distance Field Ambient Occlusion (DFAO)

• Dynamic Occlusion with Signed Distance Fields - Unreal Engine 2015 .

• Unreal 5 DFAO .

• Unlike SSAO, occlusion is computed from world-space occluders, so there are no artifacts from missing data off-screen.

• It supports dynamic scene changes; the rigid meshes can be moved or hidden, and it will affect the occlusion.

• Distance Field AO quality is determined by the resolution of the Mesh Distance Field it represents. Since AO is very soft shadowing, so even if the surfaces aren't represented properly, occlusion further from the surface will be accurate. It's often not noticeable with sky occlusion. However, make sure that the larger details of the mesh are well represented in the Mesh Distance Field for good results.

• The cost of Distance Field AO is primarily GPU time and video memory. DFAO has been optimized such that it can run on medium-spec PC, PlayStation 4, and Xbox One. Currently, it has a much more reliable cost so that it's mostly constant (with a slight dependency on object-density).

• In cases with a static camera and mostly flat surfaces, DFAO is 1.6x faster when compared to earlier implementations. In complex scenes with foliage and a fast moving camera, the latest optimizations are 5.5x faster. The cost of Distance Field AO on PlayStation 4 for a full game scene is around 3.7ms.

• DFAO relies on an SDF that encodes the minimum signed distance from any point in space to the nearest surface (positive outside, negative inside, or a variant with only unsigned distances).

Scalable Ambient Obscurance (HBAO+ / SAO)

• "Scalable Ambient Obscurance" - 2012 .

• It had nothing to do with HBAO, it's actually an optimization of Alchemy Screen-Space Ambient Occlusion.

• .

Hierarhcial Digital Differential Analyzer Global Illumination (HDDAGI)

• Hierarhcial Digital Differential Analyzer for Efficient Ray-Marching in OpenVDB - 2013 .

• PR para HDDAGI para Godot .

• HDDAGI - Godot Demo .

• This is a new global illumination system meant to supersede SDFGI.

• Key advantages are :

  • Much, much faster. Significantly lower frame time, orders of magnitude faster cascad

  • Generally higher quality (less arctifacting).

  • Much better occclusion (a  lot  less light leaked).

  • Less memory usage.
    It is meant as a drop-in replacement. Should work as a replacement for SDFGI.

• Known issues :

  •  For some reason gets DEVICE LOST on Intel GPUs. No idea why.

  •  Sharp Reflections not always play good with TAA (wobbly).

  •  Darkening (occlusion) on some corners, just like SDFGI. I tried different techniques to see if any worked better. DDGI Octahedral VSM gets rid of them, but also leaks a lot more light, so I am unconvinced. Have other ideas to try, but I don’t have infinite time 🙁

  •  SDFGI spherical harmonics turned out to be buggy and not energy conserving. This makes GI look more saturated and have more light than in HDDAGI (which some people may appreciate more), but It’s a bug 😢. Wondering how this can be compensated.

  •  Still some further pending optimizations.

• Future :

  •  Dynamic object support.

  •  High density mode (sub-probes).

SDFGI (Signed Distance Field Global Illumination)

• "SDFGI Solving the accessible Global Illumination problem in Godot" - Outubro 2022 .

  • This paper is absolutely  important to understand how SDFGI was made.

  • Requirements

    • Easy to use (no scene or object setup at import time, no setting up SDF, cards,

    • lightmaps, etc). Ideally enable with one click, no set-up.

    • Real-time (or at least fast updates).

    • Good enough quality (no light leaks -or keep to minimum-).

    • Supports both diffuse and reflected light.

    • Supports light into transparent objects.

    • Works as source of light for volumetric fog.

    • Works in all hardware that supports Vulkan, even IGP.

    • Can work in VR (so, using TAA is not required).

  • Sacrifices

    • Not the best possible quality (high frequency GI missing, has to be  compensated with screen space lighting).

    • Poor dynamic object support (dynamic objects get light from environment, but don't contribute to it). Light blocking may be added to some extent in the future.

    • Needs to use cascades.

    • Limited amount of samples means small emissive objects are spotty.

  • Previous work

    • Uses DDGI by Morgan McGuire as a base.

    • Uses Signed Distance Fields generated with Jump Flood .

• Signed Distance Fields Dynamic Diffuse Global Illumination - 2020 .

  • Global Illumination (GI) is of utmost importance in the field of photo-realistic rendering. However, its computation has always been very complex, especially diffuse GI. State of the art real-time GI methods have limitations of different nature, such as light leaking, performance issues, special hardware requirements, noise corruption, bounce number limitations, among others. To overcome these limitations, we propose a novel approach of computing dynamic diffuse GI with a signed distance fields approximation of the scene and discretizing the space domain of the irradiance function. With this approach, we are able to estimate real-time diffuse GI for dynamic lighting and geometry, without any precomputations and supporting multi-bounce GI, providing good quality lighting and high performance at the same time. Our algorithm is also able to achieve better scalability, and manage both large open scenes and indoor high-detailed scenes without being corrupted by noise.

• My opinions :

  • Knowing the Godot implementation, I find the visuals simply uninspiring.

  • It sounds bad for me to go for this solution when I didn't even use this for Godot games.

  • I've always found the performance somewhat poor, but it could simply be the low-quality implementation in the editor.

• It’s not screen-space (since it doesn’t rely only on what’s visible on screen).

• It’s also not a full path-traced solution; instead it’s a form of voxel-based GI accelerated by signed distance fields.

• Future in Godot :

  • SDFGI will be replaced either way as it has many limitations that can't be resolved (such as slow cascade generation speed).

  • A bounded GI implementation to supersede VoxelGI may be added in the future, but it's not guaranteed.

  • There are plans to replace it with HDDAGI.

• SDFGI vs VoxelGI :

  • SDFGI provides better real-time ability than baked lightmaps, but worse real-time ability than VoxelGI.

    • SDFGI supports dynamic lights, but not  dynamic occluders or dynamic emissive surfaces.

  • Using Use Occlusion  has a small performance cost, but it often results in fewer leaks compared to VoxelGI.

  • Newer on Godot, when compared to VoxelGI. SDFGI was implemented as a new feature in Godot 4.0 release.

• SDFGI - Godot .

  • SDFGI - Godot Demo .

  • SDFGI is something akin to a dynamic real-time lightmap (but it does not requiere unwrapping, nor does it use textures). It’s enabled and it automatically works by generating global illumination for static objects. It does not require raytracing, and it runs in most current (and some years old) dedicated GPUs, even medium-end budget CPUs from some years ago (SDFGI was developed and tested on a GeForce 1060, running at a stable 60 FPS).

  • Light changes are real-time , meaning any change in lighting conditions will result in an immediate update . Dynamic objects are supported only for receiving light from the environment, but they don’t contribute to lighting. Some degree of support is planned for this eventually, but not immediately.

  • SDFGI also supports specular reflections, both sharp and rough , so full PBR scenes should “just work”. In the image below you can see both of them in checkerboard roughness texture.

  • SDFGI is mostly leak free, unlike VCT techniques which are the most common in use today (like SVOGI/GIProbe/etc). As long as walls are thicker than a voxel for a given cascade, light won’t go through.

    • Leaks can be reduced significantly by enabling the Use Occlusion  property.

  • GI level of detail varies depending on the distance between the camera and surface.

  • Caviats / Issues :

    • Cascade shifts may be visible when the camera moves fast. This can be made less noticeable by adjusting the cascade sizes or using fog.

    • Good reflections and indirect lighting, but beware of leaks and visible cascade shifts.

    • SDFGI has some downsides due to its cascaded nature. When the camera moves, cascade shifts may be visible in indirect lighting.

      • This can be alleviated by adjusting the cascade size, but also by adding fog (which will make distant cascade shifts less noticeable).

    • Performance will suffer if the camera moves too fast. This can be fixed in two ways:

      • Ensuring the camera doesn't move too fast in any given situation.

      • Temporarily disabling SDFGI in the Environment resource if the camera needs to be moved at a high speed, then enabling SDFGI once the camera speed slows down.

    • When SDFGI is enabled, it will also take some time for global illumination to be fully converged (25 frames by default). This can create a noticeable transition effect while GI is still converging.

      • To hide this, you can use a ColorRect node that spans the whole viewport and fade it out when switching scenes using an AnimationPlayer node.

    • The signed distance field is only updated when the camera moves in and out of a cascade. This means that if geometry is modified in the distance, the global illumination appearance will be correct once the camera gets closer. However, if a nearby object with a bake mode set to Static or Dynamic is moved (such as a door), the global illumination will appear incorrect until the camera moves away from the object.

    • SDFGI's sharp reflections are only visible on opaque materials. Transparent materials will only use rough reflections, even if the material's roughness is lower than 0.2.

  • Performance :

    • The number of cascades can be adjusted to balance performance and quality. The number of rays thrown per frame can be adjusted in the Project Settings. The rendering can optionally be performed at half resolution (and then linearly scaled) to improve performance significantly.

  • Setting up :

    1. Make sure your MeshInstance nodes have their Global Illumination > Mode  property set to Static  in the inspector.

       • Any Mesh can receive Indirect Lighting, but only static meshes can contribute to Indirect Lighting.

       • For meshes:

         • Disabled:

           • The mesh won't be taken into account in SDFGI generation. The mesh will receive indirect lighting from the scene, but it will not contribute indirect lighting to the scene.

         • Static (default):

           • The mesh will be taken into account in SDFGI generation. The mesh will both receive and  contribute indirect lighting to the scene. If the mesh is changed in any way after SDFGI is generated, the camera must move away from the object then move back close to it for SDFGI to regenerate. Alternatively, SDFGI can be toggled off and back on. If neither is done, indirect lighting will look incorrect.

         • Dynamic (not supported with SDFGI):

           • The mesh won't be taken into account in SDFGI generation. The mesh will receive indirect lighting from the scene, but it will not contribute indirect lighting to the scene.

           • This acts identical  to the Disabled bake mode when using SDFGI.

       • For lights:

         • Disabled:

           • The light will not  be taken into account for SDFGI baking. The light won't contribute indirect lighting to the scene.

         • Static:

           • The light will be taken into account for SDFGI baking. The light will contribute indirect lighting to the scene. If the light is changed in any way after baking, indirect lighting will look incorrect until the camera moves away from the light and back (which causes SDFGI to be baked again). will look incorrect. If in doubt, use this mode for level lighting.

         • Dynamic (default):

           • The light won't be taken into account for SDFGI baking, but it will still contribute indirect lighting to the scene in real-time. This option is slower compared to Static . Only use the Dynamic  global illumination mode on lights that will change significantly during gameplay.

    2. Add a WorldEnvironment node and create an Environment resource for it.

    3. Edit the Environment resource, scroll down to the SDFGI  section and unfold it.

    4. Enable SDFGI > Enabled .

    • SDFGI will automatically follow the camera when it moves, so you do not need to configure extents (unlike VoxelGI).

  • Properties .

  • Performance and Quality .

  • To make a specific light emit more or less indirect energy without affecting the amount of direct light emitted by the light, adjust the Indirect Energy  property in the Light3D inspector.

• It is not a screen-space effect, so it can provide global illumination for off-screen elements (unlike SSIL).

• .

• .

Lighting Grid Hierarchy

• Real-Time Rendering with Lighting Grid Hierarchy - 2019 .

• Lighting Grid Hierarchy for Self-illuminating Explosions - Siggraph 2017 .

• Lighting Grid Hierarchy .

• Focusing on temporal coherency to avoid flickering in animations, we introduce lighting grid hierarchy  for approximating the volumetric illumination at different resolutions. Using this structure we can efficiently approximate the lighting at any point inside or outside of the explosion volume as a mixture of lighting contributions from all levels of the hierarchy. As a result, we are able to capture high-frequency details of local illumination, as well as the potentially strong impact of distant illumination. Most importantly, this hierarchical structure allows us to efficiently precompute volumetric shadows, which substantially accelerates the lighting computation. Finally, we provide a scalable approach for computing the multiple scattering of light within the smoke volume using our lighting grid hierarchy.

• Ray tracing can  be layered on top for visibility injection, but the technique itself does not depend on it.

• Lighting Grid Hierarchy with Raytracing Hardware Demo .

  • 100k VPL (100.000 Virtual Point Lights).

Screen-Space Directional Occlusion (SSDO)

• Real-time Approximated Global Illumination From SSAO to SSDO - 2016 .

Precomputed Radiance Transfer (PRT)

• My understanding :

  • Based on the explanations in "A Data-Driven Paradigm for Precomputed Radiance Transfer - 2022" and "Neural Precomputed Radiance Transfer - 2022", I understood that this strategy is an intermediate between baking and dynamic.

  • The idea would be to compute different types of lighting on a mesh, choosing which to apply based on the mesh's current direct lighting conditions.

  • It uses Spherical Harmonics directly, but another basis can be used.

  • ChatGPT:

    • PRT is a technique that moves expensive, direction-dependent light transport calculations offline so that, at runtime, shading under complex (often dynamic) lighting can be evaluated with a small number of dot-products.

• Precomputed Radiance Transfer for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments - Siggraph 2002 .

• .

• .

• .

• .

• .

• .

• .

• A Data-Driven Paradigm for Precomputed Radiance Transfer - Unity 2022 .

  • A Data-Driven Paradigm for Precomputed Radiance Transfer - Unity 2022 .

  • Very interesting.

  • .

  • .

• Neural Precomputed Radiance Transfer - 2022 .

  • Neural PRT:

    • .

    • A CNN encoder is the part of a convolutional neural network (CNN) that compresses input data into a compact, meaningful representation called a latent representation. It functions by progressively down-sampling and extracting hierarchical features from the input, such as an image, through a series of convolutional and pooling layers. The goal of the encoder is to reduce the input's dimensionality while retaining essential information, making it a compressed version of the original data that can then be used by a decoder  for tasks like reconstruction or pixel-level prediction

  • .

    • "Even with 5 circle harmonic bands (25 coefficients), spherical harmonics tend to cutoff the high frequency angular signals, this is visible on the mirror, for example".

• Instead of dealing with rays, PRT deals with functions on a sphere.

• Traditional PRT suggests as choice of basis:

  • Spherical Harmonics

  • Haar Wavelets.

  • Spherical Gaussians.

  • .

• The choice of basis has been one of the main domains of research.

• Usage :

  • It is designed for static  geometry (or limited deformation) and is primarily targeted at low-frequency environment lighting and shadowing / soft interreflection effects that can be precomputed.

  • Partially replaced by real-time ray-tracing / dynamic probe systems for workflows that require runtime changes. PRT is efficient for low-frequency, mostly-static content (precomputation), but for highly dynamic environments engines increasingly use real-time methods (RT + denoising, probe volumes) to handle scene changes.

• PRT Probes - The Division 1 - 2016 .

  • It is not normal PRT, but rather PRT Probes.

  • I watched about the first 20 minutes and some other segments of the video.

  • .

  • .

  • .

  • .

    • After considerations, we settled on the Half Life 2 Ambient Cube Basis (HL2), which is not a real basis but 6 vectores aligned; so it requires only six floats.

  • The probes are placed automatically via a 4x4 meters raycast grid, spawning a probe on every ray hit; also, spawn probes alongside building walls, to avoid them looking flat.

  • The storage on disk is via a 2D grid with 64x64 meters, with maximum of 1000 probes, but usually 200 probes per sector. The sectors are streamed in and out as the player moves.

  • .

  • .

    • Manhattan == Manhattan city map.

Voxel Ambient Occlusion (VXAO)

• Not in screen space.

• Nvidia VXAO - 2016 .

• Unlike VXGI which controls all illumination, VXAO is only utilized for Ambient Occlusion, enabling us to integrate it into a wider array of games and game engines that use traditional illumination technologies.

• It’s more accurate than SSAO and its derivatives, casts deeper, richer shadows that account for even the smallest details in a scene, and runs faster than other competing effects when they’re rendered at a similar quality.

• Even still, HBAO+’s Ambient Occlusion shadowing is far from the level of fidelity offered by VXAO, which avoids the caveats of screen space techniques, enabling us to deliver the most accurate and realistic Ambient Occlusion shadowing seen to date.

• With VXAO, occlusion and lighting information is gathered from a ‘world space’ voxel representation of the scene, which takes into account a large area around the viewer. Included in this voxelization are objects and details currently invisible to the viewer, and those behind the viewer, too. The result is scene-wide Ambient Occlusion shadowing, instead of ‘screen space’ shadowing based on what you can currently see. This allows AO shadows to be cast into a scene from objects near to the player but just outside of their view, and from occluded objects in the distance large enough to affect the appearance of the scene.

• Use on:

  • Rise of the Tomb Raider.

• SSAO vs HBAO+ vs VXAO, Rise of the Tomb Raider .

MSSAO (Multi-Resolution Screen-Space Ambient Occlusion)

• MSSAO 2011

• .

• You can combine results from different occlusion radius.

• It is a technique from a 2010 paper.

SSAO (Screen-Space Ambient Occlusion)

• “Where should I remove  light because it’s blocked?”

• Ray Traced Ambient Occlusion itself is an approximation of Indirect Light, and SSAO is an approximation of Ray Traced Ambient Occlusion.

  • So it's an approximation of an approximation.

• SSAO only acts on ambient light . It does not affect direct light.

• Think of SSAO as a shadow-only pass, faking soft contact shadows.

• Ray Traced AO would be the "correct" ambient occlusion, but that is kinda difficult to say as Ambient Occlusion itself is a "fake term"; SSAO approximates it.

• It's much faster then Ray Traced AO.

• Approximates ambient occlusion as a cheap GI term; bent normals can guide diffuse light injection.

• Screen-space sampling; rasterization-based.

• SSAO - Godot .

  • If you want to force SSAO to work with direct light too, use the Light Affect  parameter. Even though this is not physically correct, some artists like how it looks.

  • SSAO looks best when combined with a real source of indirect light, like VoxelGI .

• .

Combined Adaptive Compute Ambient Occlusion (CACAO)

• AMD FidelityFX Combined Adaptive Compute Ambient Occlusion .

• Released in May 2020.

• As of 2023, it became part of the AMD FidelityFX SDK.

• Updated in May 2025.

• "Artist control, etc, but deviates from the rendering equation".

Screen-Space Global Illumination Based-Invariance (SSVGI)

• The author of Radiance Cascading worked on this technique for PoE1.

• Uses exclusively image space data.

• Calculates GI for every point from scratch.

• Still needs denoising.

• Uses Screen Space Shadow Hierarchy.

  • "Shadow cascade".

Light Propagation Volumes (LPV)

• First introduced by Crytek in 2009.

• LV calculation of global illumination consists of three steps:

  • Injection virtual points lights obtained from Reflective Shadow Maps into LPV 3D grid.

  • Propagation of light intensity in grid stored in spherical harmonics coefficients.

  • Lookup for light intensity in LPV while scene rendering.

• LPV sits in the same family as Voxel-GI (both use a 3D grid) and is functionally closer to runtime probe/volume methods like DDGI than to precomputed PRT — but LPV’s propagation approach and data layout make its behavior and trade-offs distinct.

  1. Inject light into a 3D regular grid (the “volume”) from direct light sources or from virtual point lights / reflective shadow maps. The injected values are usually stored as low-order spherical harmonics (SH) or simple directional bands per cell.

  2. Iteratively propagate those values between neighboring grid cells (a diffusion / scattering sweep). The propagation step moves energy through the grid and approximates multiple diffuse bounces.

  3. At shading time, the renderer samples the grid (trilinear / tetrahedral interpolation) and uses the sampled radiance/SH to illuminate surfaces (usually only the diffuse term).

• Key implementation notes: LPV normally stores very low angular detail (few SH bands or directional channels) and relies on repeated propagation iterations to spread light. It does not explicitly store full scene geometry inside the grid (although depth/normal heuristics can be used to reduce obvious leakage).

• Usage :

  • LPV fell out of favor in many production engines because its core design produces persistent, hard-to-fix artifacts (notably light bleeding and poor directional fidelity) and because alternative runtime GI approaches (probe-based DDGI variants, voxel-cone tracing, and hardware-accelerated ray-traced GI) offer better trade-offs for modern, dynamic scenes and artist workflows. The choice is engineering- and platform-dependent; LPV still makes sense in limited cases (very low-cost, low-frequency indirect lighting), but it is no longer the common “go-to” for high-quality dynamic GI in AAA engines.

• LPV - Unreal Engine 5 .

  • Deprecated in UE5, used in UE4.

• Light Propagation Volumes - Cry Engine 3 - 2009 .

• LPV Implementation Demo .

Ambient Color

• .

• Usually 2 colors, applied depending on the normal of the surface.

Instant Radiosity ("Virtual Lights")

• It's not instant, and has nothing to do with the 'Radiosity' method.

• Approximates GI by spawning virtual point lights (VPLs) from primary light bounces.

• Then renders the scene lit by these many point lights (with importance sampling and clamping to reduce artifacts).

• It’s an approximation to many-bounce light transport.

• The method requires finding secondary bounces to spawn virtual point lights (VPLs). This is traditionally done with ray tracing.

  • However, simplified rasterization approximations (e.g., reflective shadow maps) exist that avoid explicit ray casting.

• A "Light Source" is the Sun, and a "Virtual Light" is the Moon.

• Starting from the light source, generate virtual lights placed where the light illuminates a surface, by sampling random directions from the light source.

• The virtual lights account for indirect illumination; the indirect illumination becomes direct illumination from the virtual lights.

• It converts the problem of indirect illumination into the problem of rendering many light sources.

• It can account for one or many bounces of light; you just need to keep creating virtual lights.

• This is the opposite of Path Tracing; it's called Light Tracing .

• .

• CryEngine 3:

  • This class of approaches is based on the idea of representing indirect lighting as a cloud set of virtual point light sources (VPL). Consequently, this technique has a great potential to speed up with GPU. Its main advantages are  good veracity and absence of any scene/lighting/camera constraints. Unfortunately, the main disadvantage of these methods is inadequate performance primarily because of the necessity to render at least 300-400 shadow- casting VPLs for an arbitrary scene to represent the precise solution without artifacts and flickering.

Horizon-Based Ambient Occlusion (HBAO)

• "Image-Space Horizon-based Ambient Occlusion" - Nvidia Siggraph 2008.

• Very expensive trigonometry operations and too slow at the time.

Alchemy Screen-Space Ambient Obscurance (AlchemyAO)

• HBAO+ is an optimization of this technique.

Metropolis Light Transport (MLT)

• Metropolis Light Transport .

• Siggraph 1997.

• Monte Carlo method that explores light paths in a “mutation” process, emphasizing important contributions (e.g., caustics).

• Ray tracing-based Monte Carlo.

Path Tracing

• Ray Tracing, Path Tracing, Global Illumination, BVH .

  • Great video. Very illustrative.

  • Path Tracing and Global Illumination:

    • Nothing "new" in the explanations. It's based on a lot of material I studied.

    • Sometimes it complicates some explanations, making things seem a bit magical and "untouchable"

  • BVH: Binary Volume Hierarchy.

    • Maybe it's the most relevant explanation.

    • .

  • .

    • Interesting performance statistics.

  • The video ends at 22:15.

• Global Illumination and Path Tracing .

• The standard method for computing global illumination today.

• Finds light paths starting from the camera .

• Project a ray and pick a random direction.

•   .

• It tries to find all possible light paths starting from the camera to the light source.

• The amount of light paths consider is indicated by the SPP (Samples Per pixel).

•         .

• Denoiser :

  • .

  • Use the samples from the neighboring pixels, to estimate the indirect illumination for the current pixel.

  • AI and Deep Learning is used today.

  • Spacial Denoising :

  • Temporal Denoising :

    • Cheaper and it doesn't blur.

    • For a game that has a camera moving all the time, you'll have to use:

      • Motion Vectors.

        • How things moved between frames.

        • .

      • Reject samples that were reprojected incorrectly.

      • .

  • Joint Bileteral Filter :

    • .

    • Takes into account the depth and normals.

    • .

      • My understanding is that there is less blur based on the depth buffer, in the image on the left.

Photon Mapping

• 1995 to 2001.

• Photon Mapping .

• Two-pass algorithm: first, photons are traced from light sources and stored; second, the radiance is gathered at surfaces to compute illumination.

• Handles caustics and diffuse interreflections.

• Uses Ray tracing (photon tracing) + data structure (k-d tree for photon storage).

• CryEngine 3:

  • These methods are less popular than the others in real-time graphics because of their performance issues. Usually this class of techniques is based on the classical photon-mapping approach. These methods usually use GPU texture fetching and rendering units to accelerate the photon map evaluation. The usual optimizations for these techniques are irradiance caching, importance sampling, and the incremental approach. One drawback of these methods is that the scene needs to be preprocessed to get the unique representation for the photon map. Another problem is photon map updates caused by scene and lighting changes, which leads to highly inconsistent performance and intermittent stalls.

Radiosity

• Origin of the Cornell Box .

• Radiosity is a global illumination method that solves light transport between diffuse-only surfaces by discretizing geometry into patches and solving a linear system of energy exchange.

• Produces smooth, view-independent GI (often offline or precomputed).

• Surface-based; patch-to-patch energy exchange (matrix solve). Ray tracing is optional for visibility (hemicube or ray casting).

• It doesn't use ray tracing inherently. Radiosity is based on solving a radiosity matrix (energy exchange between surface patches).

• .

• .

• .